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1.  Introduction 

The  objective  of  megaprogramming  is  to  make  possible  a  software  product¬ 
line  organization  -  one  that  can  produce  related  systems  cheaper,  better,  and  faster 
by  using  a  methodical  process  based  on  a  common  architectural  approach.  The 
STARS  program  has  been  building  up  a  technological  basis  for  megaprogramming 
for  many  years,  and  is  now  transitioning  this  technology  to  practice.  To  effectively  ap¬ 
ply  such  state-of-the-art  technology,  a  product-line  organization  needs  a  common 
Software  Engineering  Environment  (SEE)  that  is  itself  a  result  of  product-line  engi¬ 
neering.  To  use  STARS  megaprogramming  terminology,  the  SEE  must  emphasize 
domain-specific  reuse  and  support  a  systematic  SEE  process  with  extensive  auto¬ 
mation. 

This  paper  describes  how  megaprogramming  principles  are  being  applied  to 
assemble  and  integrate  the  SEE  for  one  of  the  three  STARS  Demonstration  Projects. 
It  provides  practical  lessons  learned  -  some  hard-won  -  that  should  be  useful  to  or¬ 
ganizations  planning  their  own  SEE  integration  efforts,  particularly  for  organizations 
considering  a  transition  to  megaprogramming. 

The  paper  is  organized  as  follows: 

•  Section  2,  Context,  provides  background  on  the  STARS  Program  and 
the  Air  Force/STARS  Demonstration  Project,  which  provided  the  experi¬ 
ence  for  this  report. 

•  Section  3,  Demonstration  Project  SEE,  describes  the  Demonstration 
Project  SEE  and  provides  a  brief  history  of  SEE  assembly  and  integra¬ 
tion. 

•  Section  4,  Lessons  Learned,  summarizes  the  lessons  learned  to  date 
on  the  Demonstration  Project,  and  elaborates  selected  lessons  in  more 
depth. 

•  Section  5,  Megaprogramming  and  SEE  Integration,  reflects  upon  the 
above  experience,  tying  together  the  topics  of  Megaprogramming  and 
SEE  Integration. 

•  Section  6,  Conclusion,  summarizes  the  key  points  of  this  paper. 
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2.  Context 


2.1  The  stars  Program 

The  ARPA  STARS  program  is  a  technology  development,  integration  and  tran¬ 
sition  program  to  demonstrate  a  process-driven,  domain  specific  reuse-based  ap¬ 
proach  to  software  engineering  that  is  supported  by  appropriate  tool  and  environment 
technology  -  an  approach  referred  to  as  “megaprogramming”. 

2.1.1  Megaprogramming 

Megaprogramming  is  a  product-line  (family  of  systems)  approach  to  the  crea¬ 
tion  and  maintenance  of  software  intensive  systems.  It  is  characterized  by  the  reuse 
of  software  life-cycle  assets  within  a  product-line  including  common  architecture, 
models  and  components.  Megaprogramming  also  includes  the  definition  and  en¬ 
actment  of  disciplined  processes  for  the  development  of  applications  and  the  evolu¬ 
tion  of  the  product-line  as  a  whole.  Finally,  megaprogramming  calls  for  automated 
support  for  the  process  via  advanced  software  engineering  environment  (SEE)  tools 
and  integration  among  those  tools. 

STARS  has  three  technology  thrusts  that  it  views  as  essential  for  megapro¬ 
gramming: 

•  Domain-Specific  Reuse  -  STARS  contends  that  high-payoff  reuse  is 
best  achieved  on  software  “product-lines”,  where  a  coherent  architec¬ 
tural  approach  can  be  used  for  all  of  the  applications.  The  product-line 
will  typically  be  managed  by  a  single  individual  who  will  assure  that 
adequate  engineering  is  performed  at  the  domain  level. 

•  Systematic  Process  -  In  addition  to  a  common  architectural  approach, 
a  common  process  framework  is  needed  so  that  the  engineering  of 
each  application  in  the  product-line  is  performed  with  proper  attention  to 
commonality  and  quality. 

•  Automated  Support  -  To  support  the  above  two  thrusts,  STARS  seeks 
to  bring  the  best  available  SEE  tools  and  integration  technology  to  bear. 

For  a  more  in-depth  introduction  to  the  STARS  program  and  the  notions  of 
megaprogramming,  please  refer  to  [Trimble94]. 

2.1.2  Demonstration  Projects 

The  STARS  program  mission  is  to  accelerate  the  transition  to  the  megapro¬ 
gramming  paradigm.  Key  vehicles  for  bringing  this  about  are  the  three  STARS  Dem¬ 
onstration  Projects  -  one  with  each  of  the  three  services  (Air  Force,  Army,  and  Navy)  - 
which  are  applying  the  principles  of  megaprogramming  to  the  development  of  DoD 
systems.  Each  STARS  Demonstration  Project  is  documenting  qualitative  and  quan¬ 
titative  experience  about  the  benefits  and  costs  of  megaprogramming,  as  well  as  the 
effectiveness  of  specific  tools  and  techniques.  This  experience  is  to  be  used  to  initi¬ 
ate  the  transition  of  megaprogramming  practices  to  each  Demonstration  Project’s 
parent  organization. 
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2.2  The  Air  Force/STARS  Demonstration  Project 

In  1992  Air  Force  Space  Command’s  (AFSPC)  Space  and  Warning  System 
Center  (SWSC)’  won  the  bid  for  the  Air  Force’s  STARS  Demonstration  Project.  The 
SWSC  is  responsible  for  the  maintenance  and  evolution  of  software  for  the  C^  cen¬ 
ters  at  the  Cheyenne  Mountain  Air  Force  Station  (CMAS)  -  which  have  the  mission  for 
national  attack  warning/assessment  and  space  surveillance/defense/control.  A  large 
number  of  mission-critical  systems  are  involved,  with  a  high  annual  maintenance 
cost. 

The  SWSC,  determined  to  apply  new  software  technologies  to  reduce  mainte¬ 
nance  costs,  had  already  been  working  to  build  up  a  megaprogramming  capability; 
and  the  partnership  with  STARS  was  a  natural  way  to  accelerate  the  transition. 

The  Demonstration  Project  application  being  developed  is  the  Space  Com¬ 
mand  and  Control  Architectural  Infrastructure  (SCAI)  System,  which  will  be  a  mobile 
space  control  capability. 


^  Effective  Februnary,  1995,  the  SWSC  is  transfering  to  the  Air  Force  Materiel  Command  (AFMC)  and  will  be  known  as  the  Space  and 
Warning  Systems  Directorate  (SWSD). 
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Table  1  provides  a  summary  of  the  progress  to  date  on  the  project  -  in  terms  of 
the  three  STARS  megaprogramming  technology  thrusts. 


Original  SWSC  Posture 

Accomplishments  since  Establishing 

STARS  Partnership 

Activities  in  Progress 
(as  of  1/95) 

Domain- 

Specific 

Reuse 

•  Strong  architecture, 
based  on  Reusable 
Integrated  Command 
Center  (RICC)  archi¬ 
tectural  infrastaicture 

•  Strong  emphasis  on 
Open  Systems,  com¬ 
mercial  tools 

•  Domain  models  un- 
den/vay 

•  Commitment  to  Ada 

•  Demonstrated  viability  of  architectural  ap¬ 
proach 

•  Defined  tailored  specification  standard  based 
on  Cleantoom,  MIL-STD  498,  and  others 

•  Completed  object-based  application  models; 
specified  SCAI  system  and  first  two  SCAI  re¬ 
leases 

•  Developed  and  tested  SCAI  Release  1 

•  Developing  SCAI  Re¬ 
leases  2;  specifying  Re¬ 
lease  3 

•  Refining  product-line  ar¬ 
chitectural  framework 

•  Continuing  to  devetap 
domain  models 

Systematic 

Process 

•  Understanding  of  im¬ 
portance  of  process 

•  SWSC  Software  Engi¬ 
neering  Process 

Group  (SEPG)  estab¬ 
lished 

•  Semi-formal  process 
definition  in  selected 
areas 

•  Corporate  Information 
Management  (CIM) 
IDEF  model  undenvay 

•  Instituted  formal  approach  to  process  definition, 
based  on  STARS/SEI  collaboration 

•  Created  a  product-line  process  architecture 

•  Integrated  00,  Cleanroom,  and  the  Ada  Proc¬ 
ess  Model  methods 

•  Formally  defined  processes  for  Application  En¬ 
gineering  (AE) 

•  Launched  a  major  metrics  initiative 

•  Automated  staff  hour  and  defect  metrics  collec¬ 
tion 

•  Nearing  completion  of 
formal  definition  of  CM 
prrxess 

•  Beginning  formal  defini¬ 
tion  of  Domain  Engi¬ 
neering  process 

•  Working  on  second 
round  of  AE  specification 
process 

•  Using  automated  proc¬ 
ess  rtxjdeling  and  en¬ 
actment  support  for 

SCAI  Release  2  and  3 

Automated 

Support 

•  Commitment  to  Ra¬ 
tional  Ada  support 
product-fine 

•  Commitment  to  Uni¬ 
versal  Network  Ar¬ 
chitecture  Services 
(UNAS),  and  RICC 
for  Architectural  Infra¬ 
structure 

•  Integrated  a  state-of-the-art  open  systems  SEE: 
IBM  and  Sun  platfonns.  Rational  and  TRW 
toolsets 

•  Installed  advanced  process  support  toolset;  en¬ 
coded  and  began  automated  enactment  of  SCAI 
Release  2  and  3  processes 

•  Instituted  automated  tracking  capability  for 
problems,  action  items,  etc. 

•  Began  use  of  Rational  SoDA  for  automated 
document  production 

•  Enhandng  the  functional¬ 
ity  and  integration  of  the 
process  tools 

•  Applying  Amadeus  to 
automate  collection  of 

SEE  usage  metrics 

•  Extending  process  auto¬ 
mation  across  geo¬ 
graphical  locations 

Table  1.  Demonstration  Project  -  Megaprogramming  Progress  and  Status 


3.  Demonstration  Project  SEE 
3.1  SEE  Composition 

The  Demonstration  Project  SEE  Is  composed  of  approximately  50  worksta¬ 
tions  connected  to  3  server-class  machines.  It  is  about  evenly  divided  between  Sun 
and  IBM  Unix-based  platforms.  The  network  is  distributed  across  two  geographical 
sites  and  operates  with  restricted,  classified  access. 
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The  SEE  is  populated  with  an  integrated  set  of  tools  to  support  end-user  func¬ 
tionality,  as  depicted  in  Figure  1.  In  this  diagram,  we  cite  only  end-user  tools,  but 
there  are  many  “infrastructure”  facilities,  such  as  relational  database  management 
systems  (Sybase  and  Oracle  are  both  used  on  the  SCAI  SEE). 
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Table  2  identifies  the  supplier  of  each  tool  shown  in  Figure  1.  As  shown,  the 
SWSC  has  selected  Rational  and  TRW  as  major  toolset  providers  for  the  Demon¬ 
stration  Project.  Also  shown  in  the  table  are  four  tools  that  have  been  developed  with 
STARS  support. 


Type  1  Tool  Name  |  Vendor/Developer  |  Purpose 

Rational  Ada  Development  Toolset 

Apex 

Rational 

Code  creation  and  testing 

RCI 

Rational 

Interfaces  Apex  with  other  Ada  compil¬ 
ers 

Rose 

Rational 

Object  oriented  analysis  and  design 

SoDA 

Rational 

Automated  document  generation 

VADS 

Rational 

Verdix  compiler 

1  TRW  Architectural  Infrastructure  Support  Toolset  I 

RICC  Tools 

TRW 

Application  display,  message,  and  da¬ 
tabase  definition 

SALE 

TRW 

Application  network  definition  (used 
with  UNAS) 

UNAS 

TRW 

Application  network  manager 

1  STARS-Supported  Tools  1 

Amadeus 

Amadeus  Software  Research, 
Inc. 

Metrics  repository  and  analysis 

PEAKS 

Cedar  Creek  Process  Engi¬ 
neering  (ccPE) 

Process  modeling,  planning,  and  plan 
simulation 

ProjectCatalyst 

Software  Engineering  Tech¬ 
nology  (SET) 

Low-level  process  definition  and  proc¬ 
ess  execution 

toolSET  certify 

SET 

Cleanroom  certification  testing  support 

Other 

'ools  1 

CAT/Compass 

Robbins-Gioia 

Project  management 

CMVC 

IBM 

Configuration  management  and  track¬ 
ing  system 

FrameMaker 

Frame  Technology,  Inc. 

Documentation  and  publication 

ProDAT 

Embedded  Computer  Re¬ 
source  Support  Improvement 
Program  (ESIP),  managed  by 
Sacramento/ALC 

IDEF-oriented  process  definition 

Process  Weaver 

Cap  Gemini  America 

Process  workflow  manager 

SunTools 

Sun 

General  office  support 

Teamwork/IM 

Cadre  Technologies 

Table  2.  Demonstration  Project  SEE  Tool  Suppliers 


The  integration  of  the  SEE  tools  is  accomplished  through  a  combination  of 
techniques  and  mechanisms.  Control  integration  (tool  invocation  and  communica¬ 
tion)  is  provided  by 

•  IBM  AIX  SDE  WorkBench/6000  broadcast  messaging  service,  the  Proc¬ 
ess  Weaver  message  service,  operating  system  process  services,  and 
TCP/IP  sockets.  The  WorkBench  and  operating  system  process  control 
provided  local  service  within  a  user's  machine  session.  Process 
Weaver  and  TCP/IP  provided  service  between  users  and  between  ma¬ 
chines. 
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•  Data  integration  is  provided  by  the  Oracle  Relational  Database  Man¬ 
agement  System  (RDBMS)  and  the  operating  system  file  system. 

•  Presentation  and  user  interface  integration  is  provided  by  the  X  Window 
System  and  the  Motif  window  manager. 

•  Process  integration  is  provided  by  the  STARS-sponsored  Process  Sup¬ 
port  Environment  toolset;  PEAKS,  ProjectCatalyst  (in  conjunction  with 
Process  Weaver). 

3.2  HISTORY 

The  Demonstration  Project  began  in  1992  and  is  scheduled  to  complete  in 
1995.  The  first  year,  the  Preparation  Phase,  was  intended  to  lay  the  groundwork  for 
the  final  two  years,  the  Performance  Phase.  This  paper  was  written  just  after  the  first 
year  of  the  Performance  Phase. 

3.2.1  Preparation  Phase  (11/92-10/93) 

Early  in  1993,  a  joint  team  of  Loral  STARS  and  AF  engineers  was  established 
to  handle  the  SCAI  SEE.  During  the  Preparation  Phase,  the  team  developed  an  initial 
overall  SEE  integration  strategy,  documented  in  Version  2.0  of  the  SCAI  Demonstra¬ 
tion  Project  Management  Plan  (SDPMP). 

The  SCAI  project  planned  to  simultaneously  develop  several  key  aspects  of  its 
overall  approach.  Early  decisions  had  to  be  made  about  SEE  composition  prior  to 
detailed  understanding  of  the  process  the  SEE  was  to  support.  The  key  early  deci¬ 
sions  were  to  use  IBM  workstations.  Rational  Ada  development  software,  and  TRW 
domain-specific  support  software.  The  SWSC  -  committed  to  the  use  of  Ada  for  the 
application  product-line  -  selected  the  Rational  Ada  development  toolset  as  a  key  part 
of  the  SEE.  The  application  architectural  strategy  is  based  on  a  TRW-originated  ar¬ 
chitectural  infrastructure,  and  the  SWSC  has  adopted  the  corresponding  TRW  toolset 
as  another  key  part  of  the  SEE.  In  addition,  the  Air  Force  decided  to  sponsor  en¬ 
hancements  to  the  TRW  toolset,  and  movement  continued  towards  commercializa¬ 
tion. 


A  major  new  focus  for  the  SCAI  project  was  process  support  technology.  Both 
the  SWSC  and  STARS  organizations  were  committed  to  improving  the  processes 
used  on  the  SCAI  project  -  and  jointly  decided  to  explore  the  emerging  technologies 
of  process  modeling,  project  process  management,  process  execution,  and  auto¬ 
mated  metrics  collection.  It  was  decided  to  proceed  with  development  of  the  Loral 
STARS  Process  Support  Environment  (PSE)  toolset  during  the  Preparation  Phase 
and  into  the  Performance  Phase.  The  PSE  was  designed  to  provide  advanced  proc¬ 
ess  modeling,  planning  and  execution  capability. 

During  the  Preparation  Phase,  the  SEE  hardware  and  software  was  delivered 
in  two  major  installments  and  integrated  with  the  existing  Sun  workstations.  The  SEE 
was  used  primarily  to  develop  system  and  software  engineering  models  that  cap¬ 
tured  domain  understanding  and  laid  the  groundwork  for  the  SCAI  specification  effort. 
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3.2.2  First  Year  of  the  Performance  Phase  (11/93-10/94) 

During  the  first  year  of  the  Performance  Phase,  the  team  planned  and  ordered 
the  third  and  final  major  SEE  installment.  Due  to  changes  in  STARS  funding,  the  in¬ 
stallation  was  delayed  significantly,  and  though  originally  planned  for  April  1994,  it 
was  not  installed  until  October.  The  impact  of  this  delay  was  to  reduce  the  team's 
productivity  somewhat,  although  adjusted  work  patterns  and  interim  SEE  assets 
helped  offset  this  impact.  The  STARS  PSE  toolset,  also  delivered  later  than  originally 
anticipated,  was  used  for  the  SCAI  Release  2  work.  During  this  period,  experience 
with  the  SEE  was  used  to  define  a  major  update  to  the  PSE,  which  is  now  being  used 
for  SCAI  Release  3  work. 

At  the  start  of  the  Performance  Phase,  several  tools  were  still  under  evaluation, 
including  IBM  CMVC,  Amadeus,  the  STARS  PSE  toolset,  SoDA,  and  ProDAT.  The 
primary  means  of  evaluating  these  tools  was  to  conduct  pilots.  Based  on  pilot  usage, 
all  of  the  tools  were  accepted  for  use.  The  pilots  took  unanticipated  labor,  especially 
the  PSE. 

SEE  integration  activity  during  this  period  resulted  in  improvements  to  the  PSE 
(elaborated  later  in  this  paper),  configuration  management,  documentation  produc¬ 
tion,  metrics,  and  overall  engineering  database  analysis. 

At  the  project  level,  there  were  substantial  adjustments  to  the  approach  and  to 
the  process  -  necessitating  adjustments  to  SEE  strategy,  design  and  implementa¬ 
tion. 

3.3  PRAGMATIC  FACTORS 

The  following  is  a  recap  of  some  of  the  constraints,  considerations  and  other 
practical  factors  that  affected  the  establishment  of  the  SEE. 

•  The  AF  and  each  of  their  contractors  had  an  installed  base  of  software 
with  which  they  were  familiar.  The  selection  of  the  SCAI  SEE  products 
required  significant  consensus  efforts  to  enhance  this  existing  base. 

•  The  SEE  included  diverse  products  from  many  vendors,  requiring  di¬ 
verse  integration  strategies.  Some  tools  were  part  of  single-vendor 
toolsets,  however,  lessening  the  need  for  integration. 

•  The  combined  team  (Air  Force,  Air  Force  contractors,  and  Loral)  worked 
in  different  locations  and  different  time  zones.  For  the  first  two  years  of 
the  project,  these  groups  were  forced  to  use  segregated  SEEs.  More 
recently  a  link  was  established  between  the  two  primary  project  loca¬ 
tions.  The  geographical  separation  also  impeded  the  Loral  team's  abil¬ 
ity  to  support  SEE  activities. 

•  The  application  is  classified,  which  required  the  SEE  to  be  classified  as 
well  -  compounding  the  factors  cited  in  the  preceding  point. 

•  Several  products  (e.g.,  process  support  tools)  had  release  and  devel¬ 
opment  delays.  The  products  were  less  mature  than  expected.  In  addi- 
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tion,  because  of  the  need  for  advanced  tools,  the  Air  Force  conducted 
several  Beta  test  and  pilot  evaluation  activities. 

•  Products  and  prices  changed  during  the  selection  and  acquisition  pe¬ 
riod.  Budgets  and  plans  required  several  adjustments.  In  addition, 
STARS  funding  delays  required  shifting  some  acquisitions  into  late 
1994,  and  funding  reductions  required  reduction  in  SEE  scope  and 
function. 

3.4  ACCOMPLISHMENTS 

•  SEE  Engineering:  The  team  piloted  and  adopted  several  new  tools 
(Amadeus,  IBM  CMVC,  PSE,  SoDA,  ProDAT).  The  first  release  of  the 
PSE  was  completed  and  delivered.  The  team  gathered  usage  experi¬ 
ence  and  scheduled  a  major  PSE  upgrade  (completed  in  late  1994  and 
now  in  use).  A  prototype  integration  between  IBM  CMVC  and  Rational 
CMVC  was  built.  An  artifact  database  study  was  completed,  laying  the 
groundwork  for  improvements  to  overall  SEE  data  integration.  The  team 
instituted  the  use  of  IBM  CMVC  for  general  purpose  tracking  (problems, 
action  items,  etc.). 

•  Process  Support:  The  team  applied  the  PSE  to  SCAI  Release  2,  which 
provided  usage  experience  leading  to  a  major  PSE  upgrade.  The  team 
began  using  the  ESIP-sponsored  ProDAT  tool  to  support  process  defi¬ 
nition,  and  they  began  using  Amadeus  for  labor  metrics  collection. 

•  Domain/Application  Engineering  Support:  The  team  began  applying 
state-of-the  art  tools  for  SCAI  engineering  work,  including  Rational  Rose 
(object-oriented  domain/application  modeling),  RICC  Tools 
(architectural  infrastructure  development),  and  Rational  Apex  (Ada  de¬ 
sign/development). 

•  SEE  Improvement  Process:  Two  user  surveys  were  conducted  which 
provided  valuable  input  to  the  overall  development  of  the  SEE.  IBM 
CMVC  is  now  being  used  to  support  SEE  improvement  procedures 
once  handled  manually.  This  includes  support  for: 

-  System  management  work  order  processing, 

SEE  product  problem/enhancement  tracking,  and 
Commercial  tool  vendor  feedback  (partially  implemented  proc¬ 
ess). 

•  SEE  Technology  Transition:  To  perform  technology  transition,  the  team 
conducted  classes  and  pilots  to  introduce  new  tools.  They  conducted 
presentations  and  demonstrations  of  the  SEE  to  the  SWSC  and  to  out¬ 
side  organizations. 

•  Team  Connectivity:  Progress  has  been  slow  in  creating  useful  elec¬ 
tronic  team  connectivity.  This  is  largely  due  to  logistical  problems  asso¬ 
ciated  with  adding  new  outside  connections  into  the  classified  enclo¬ 
sure  within  the  SWSC.  Connectivity  with  one  prime  contractor,  Kaman 
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Sciences,  was  achieved  by  physically  relocating  the  personnel.  Con¬ 
nectivity  with  another  prime  contractor,  TRW,  was  achieved  by  imple¬ 
menting  a  secure  link  to  their  facility.  The  project  has  coped  well  with  the 
limitations  -  e.g.,  software  development  productivity  has  exceeded  ex¬ 
pectations  for  the  SCAI  Release  1  effort  -  but  it  is  clear  that  overall  syn¬ 
ergy  could  have  been  better  if  all  project  personnel  had  been  linked  on  a 
common  SEE  from  the  outset. 
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4.  Lessons  Learned 


4.1  Overview 

The  lessons  learned  presented  in  this  paper  are  based  on  a  more  complete 
set  of  SEE  lessons  documented  in  the  Draft  Version  2.0  of  the  Air  Force/STARS 
Demonstration  Project  Experience  Report  [DemExp95].  Table  3  itemizes  lessons 
from  the  Experience  Report  that  are  particularly  relevant  to  the  two  focus  areas  ad¬ 
dressed  by  this  paper;  megaprogramming  and  integration.  Since  space  does  not 
permit  treatment  of  all  of  the  lessons  in  Table  3,  we  have  chosen  a  subset  for  more 
discussion  in  Section  4.2,  Elaboration  of  Selected  Lessons  Learned  -  the  lesson 
numbers  are  provided  in  the  “Lesson  #”  column  of  the  table. 

The  table  also  cross-references  each  lesson  as  to  its  relevance  to  the  three 
megaprogramming  technology  thrusts:  domain-specific  reuse,  systematic  process, 
and  automated  support  (see  Section  2.1.1,  on  page  2,  for  a  definition  of  these  cate¬ 
gories).  These  designations  in  this  table  refer  to  how  reuse,  process  and  automation 
apply  to  the  SEE  itself. 

The  lessons  are  grouped  into  the  following  life-cycle  activities: 

•  Domain  Engineering  -  developing  a  strategy  for  the  family  of  SEEs  that 
will  support  a  product-line  organization. 

•  SEE  Management  -  managing  the  administrative  and  engineering  ac¬ 
tivities  for  a  SEE,  with  emphasis  on  aspects  present  when  providing  a 
SEE  for  a  significantly  new  way  of  doing  business  -  such  as  megapro¬ 
gramming. 

•  SEE  Architecture  -  engineering  a  common  architecture  for  a  SEE  prod¬ 
uct-line. 

•  Platform  and  Tool  Selection  -  selecting  hardware,  networking  and 
software  tools  for  a  new  SEE. 

•  SEE  Integration  -  combining  the  functions  of  the  SEE  so  that  there  is  re¬ 
duced  end-user  perception  of  the  SEE’s  individual  components. 

•  SEE  Improvement  -  gathering  information  about  the  SEE’s  functions, 
performance,  maintainability,  etc.,  and  pursuing  needed  improvements. 

•  Technology  Transition  -  transitioning  new  SEE  approaches  and  tech¬ 
niques  to  SEE  engineers  and  end-users. 
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Lesson 

Category 

Brief  Lesson  Statement 

Lesson  q 

Megaprogramming 

Relevance 

Reuse 

Process 

Automation 

Domain  Engi¬ 
neering 

^  product  -line  mentality,  complete  with  domain  engineering,  is  appropriate 
for  the  SEE  product  line 

1 

X 

X 

H 

Establish  a  focal  point  SEE  organization  for  the  entire  SEE  product  line 

X 

X 

SEE  Man¬ 
agement 

Managing  change  in  the  domain  of  the  SEE  is  a  key  challenge  for  organiza¬ 
tions  transitioning  to  megaprogramming 

3 

X 

■ 

Stringent  security  reguirements  represent  a  significant  hurdle  to  SEE  as¬ 
sembly  and  integration 

X 

■ 

/V  project  should  place  early  priority  on  intra-and  inter-project  communica¬ 
tion  and  coordination 

■ 

X 

SEE  engineering  "bandwidth"  will  be  impacted  by  a  surprising  amount  of 
non-technical  work 

4 

■ 

X 

(K  SEE  "czar''  is  reguired  for  effective  management  of  the  SEE  activity 

B 

X 

SEE  architecture  must  be  developed  incrementally 

6 

X 

X 

Platform 
and  Tool 
Selection 

Heterogeneous  open-systems  platforms  can  provide  an  important  degree  of 
flexibility 

1 

X 

■ 

X 

A  project  must  be  judicious  about  the  number  of  new  tools 

X 

A  project  should  be  cautious  about  committing  to  tools  still  under  develop¬ 
ment 

■ 

H 

X 

Pilots  are  an  important  vehicle  for  both  tool  selection  and  tool  usage 

8 

X 

X 

SEE  Integra¬ 
tion 

Logistical  factors,  such  as  delays  in  shipment,  nuances  in  licensing,  etc., 
can  significantly  complicate  SEE  assembly  and  integration 

X 

Upgrades  to  an  operating  system  (or  other  SEE  infrastructure  components) 
can  disrupt  integration 

9 

■ 

m 

High-payoff  integration  can  result  from  selecting  a  vendor  whose  toolset 
evolution  objectives  align  with  your  organization’s  goals 

10 

m 

Acguiring  a  single  vendor  toolset  is  usually  more  cost-effective  than  inte¬ 
grating  separate  tools 

11 

■ 

m 

Maintaining  process  information  in  multiple  forms  poses  a  significant  main¬ 
tenance  challenge 

12 

m 

X 

Artifact  management  (notably  configuration  management)  is  a  central  inte¬ 
gration  issue 

13 

X 

X 

■ 

Use  of  BMS  messaging  services  reguired  unanticipated  engineering  effort 
to  provide  guaranteed  message  delivery 

14 

X 

A  Process  Support  Environment  can  provide  an  effective  SEE  integration 
ayer 

15 

X 

X 

X 

SEE  Im¬ 
provement 

Medium-to-large  projects  need  a  SEE-supported  problem  tracking  system 

X 

X 

Management  of  the  SEE  can  be  enhanced  via  an  automated  tracking  tool 

X 

X 

A  project  can  use  an  automated  tracking  tool  as  the  basis  for  systematic 
feedback  to  vendors  about  their  products. 

H 

X 

Process-driven  databases  are  a  good  basis  for  metrics 

m 

X 

X 

Periodic  SEE  surveys  are  essential  to  the  organization’s  SEE  improvement 
cycle 

17 

X 

■ 

The  wide  variety  of  new  approaches  and  tools  introduced  on  a  new  SEE 
necessitates  a  substantial  investment  in  technology  transition 

■ 

X 

Table  3.  Summary  of  Lessons  Learned 
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Automation  X  x  x  x  x  x  x  x  x  x 


4.2  Elaboration  of  Selected  Lessons  Learned 


4.2.1  Domain  Engineering  Lessons 

“Domain  engineering"  refers  to  the  identification  and  disciplined  exploitation  of 
commonality  across  a  family  of  related  systems  -  and  is  a  major  emphasis  in  a  me¬ 
gaprogramming  organization.  A  key  objective  of  the  Demonstration  Project  is  to  es¬ 
tablish  a  domain  engineering  baseline  for  the  SWSC  product-line  -  models,  common 
architectural  framework,  similar  processes,  strategic  tools,  etc.,  that  will  allow  future 
applications  in  the  product-line  to  be  built  using  the  same  methodology. 

We  are  now  of  the  belief  that  the  SEE  which  supports  the  development  of  the 
product-line  applications  actually  constitutes  a  product-line  of  its  own.  Accordingly, 
this  subsection  supplies  two  observations  about  the  applicability  of  domain  engi¬ 
neering  principles  to  the  SEE. 

Lesson  1.  A  product-line  mentality,  complete  with  domain  engineering,  is  appro¬ 
priate  for  the  SEE  product  line. 

The  development  of  an  architecture  for  a  product-line  SEE  requires  a  prod¬ 
uct-line  mentality  for  the  SEE  itself  -  complete  with  SEE  domain  engineer¬ 
ing. 

This  objective  -  to  support  the  future  SWSC  product-line  requirements  -  has 
led  to  SEE  thought  processes  that  are  analogous  to  SCAI  application  do¬ 
main  thought  processes.  Upon  reflection,  this  is  entirely  appropriate.  In  the 
future  application  product-line  organization,  there  will  be  multiple  logical 
SEEs  -  one  for  each  application  being  developed.  These  SEEs  will  share 
many  common  hardware  and  software  assets,  but  each  project  will  have  a 
unique  view  of  these  assets  -  which  will  guide  instantiation  and  augmenta¬ 
tion  activities  to  produce  its  own  tailored  realization  of  the  SEE. 

The  requirements  for  these  SEEs  are  dictated  by  the  organization’s  com¬ 
mon  process  (the  same  process  framework,  but  tailored  realizations)  and 
the  common  application  construction  methodology  (same  architectural  ap¬ 
proach,  but  some  tailoring  in  each  application  instantiation).  Thus,  to  deliver 
end-user  functionality  “cheaper,  better,  faster”  to  the  product-line  organiza¬ 
tion,  SEE  engineers  must  perform  domain  engineering  of  the  SEE  domain. 

Looking  back  over  the  experience  to-date  with  the  SCAI  SEE  (and  its  fore¬ 
runners  at  the  SWSC  prior  to  the  Demonstration  Project),  it  is  clear  that  do¬ 
main  engineering  thought  processes  have  influenced  the  acquisitions  and 
integrations  that  have  led  to  our  current  SEE. 

This  lesson  provides  the  main  theme  for  this  paper,  and  it  is  discussed  in 
some  detail  in  Section  5,  Megaprogramming  and  SEE  Integration,  starting 
on  page  24. 
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Lesson  2.  Establish  a  focal  point  SEE  organization  for  the  entire  SEE  product  line. 

A  product-line  organization  should  establish  a  focal  point  SEE  organization 
responsible  for  both  SEE  engineering  and  SEE  management  for  the  entire 
product-line.  Having  an  organization  responsible  for  the  SEE  product-line 
ensures  that  the  SEEs  are  managed  as  a  product  line  and  that  product  line 
activities  (such  as  domain  analysis)  are  done.  The  SWSC  Software  Engi¬ 
neering  Process  Group  established  an  Integrated  Process  Team  (IPT)  to 
address  the  proliferation  of  SEE  tools  across  the  SWSC  directorates,  and  in 
doing  so  acknowledged  the  problem  of  “stovepipes”'  within  the  SEE  do¬ 
main.  As  the  SWSC  moves  toward  a  product-line  way  of  doing  business  for 
its  end-user  applications,  it  will  need  to  move  to  a  SEE  product-line  to  sup¬ 
port  it. 

4.2.2  SEE  Management  Lessons 

Lesson  3.  Managing  change  in  the  domain  of  the  SEE  is  a  key  challenge  for  or¬ 
ganizations  transitioning  to  megaprogramming. 

For  most  organizations,  transitioning  to  megaprogramming  represents  sig¬ 
nificant  change  -  with  corresponding  pressure  on  the  SEE  to  change  to 
support  the  new  ways  of  doing  business.  Well-intended  visionaries  will 
seek  the  latest  tools  and  technologies  -  which  is  justifiable,  since  there  are 
many  gaps  in  proven  tooling  for  megaprogramming  (support  for  domain 
engineering,  integrated  process  definition  and  enactment,  architecture- 
directed  program  generation,  etc.). 

However,  such  changes  bring  management  headaches  as  well  -  such  as 
the  following,  all  of  which  have  been  encountered  on  the  Demonstration 
Project; 

•  Planning  uncertainty  -  due  to  such  factors  as  slipped  delivery  dates  and 
integration  mismatches; 

•  SEE  instability  -  due  to  the  newness  of  the  tools,  including  the  possibility 
that  a  tool  must  ultimately  be  thrown  out; 

•  SEE  technology  transition  issues  -  due  to  such  factors  as  paradigm 
mismatches,  extensive  need  to  train  users,  and  the  possible  need  to 
adapt  current  processes  to  take  advantage  of  new  tool  capabilities. 

There  is  no  formula  forjudging  where  to  draw  the  line,  but  here  are  some 
weapons  in  the  manager’s  arsenal: 

•  A  SEE  engineering  staff  that  includes  someone  with  extensive  experi¬ 
ence  with  assembling  and  integrating  SEEs  -  preferably  with  some  bat¬ 
tle  scars  with  respect  to  the  pitfalls  of  new  tools; 

•  Piloting  (see  also  lesson  8);  and 


“Stovepipe”  systems  are  systems  that  are  developed  independently,  with  no  intent  to  share  architecture  or  information  except  at  external 
interfaces. 
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•  Common  sense. 

The  main  point  is  to  be  aware  that  change  itself  is  a  key  SEE  challenge. 

Lesson  4.  SEE  Engineering  “bandwidth"  wiii  be  impacted  by  a  surprising  amount 
of  non-technicai  work. 

An  organization  changing  to  a  significantly  new  way  of  doing  business  (such 
as  megaprogramming)  must  address  a  challenging  mix  of  technical  and 
non-technical  SEE  issues,  with  a  surprisingly  large  percentage  of  this  effort 
going  to  non-technicai  issues.  Further,  because  the  non-technical  issues 
constrain  the  engineering  solution,  proportionately  less  engineering  band¬ 
width  is  available  to  address  technical  issues. 

In  our  case,  SEE  engineering  was  complicated  by  such  non-technical  fac¬ 
tors  as: 

•  The  degree  of  change  (cited  in  the  prior  lesson); 

•  The  continuing  evolution  of  the  processes  to  be  supported  by  the  SEE; 

•  Significant  changes  in  budget  and  timing; 

•  The  geographical  separation  of  personnel  (initially,  three  major  contrac¬ 
tors  were  located  at  different  locations  -  although  this  is  becoming  less 
of  a  problem,  since  the  team  is  being  consolidated  in  one  location);  and 

•  The  classified  nature  of  the  SCAI  application  (this  necessitated  the  SEE 
to  be  classified  -  which  in  turn  degraded  external  electronic  communica¬ 
tion  and  diminished  the  ability  of  off-site  personnel  to  support  the  proj¬ 
ect). 

Lesson  5.  A  SEE  “czar"  is  required  for  effective  management  of  the  SEE  activity. 

In  the  face  of  the  inevitable  uncertainty  in  requirements,  and  the  need  for 
long  lead  times  for  acquisition  and  meaningful  integration,  appointing  a 
qualified  SEE  “czar”  early  in  the  program  is  necessary.  This  lead  person  will 
be  a  single  point  of  responsibility  for  the  project’s  SEE  and  will  coordinate 
both  SEE  engineering  and  planning,  making  it  easier  to  force  certain  strate¬ 
gic  decisions  early  -  despite  the  inevitable  lack  of  complete  information. 

Some  key  SEE  issues  that  should  be  addressed  early  are 

•  Artifact  definition  and  management,  especially  configuration  manage¬ 
ment; 

•  Project-wide  tracking  support  (problems,  issues,  action  items,  etc.);  and 

•  Metrics  instrumentation  strategy. 
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It  is  also  essential  to  have  an  experienced  lead  engineer  devoted  to  such 
engineering  functions  as  SEE  architecture,  tool  selection  guidance,  integra¬ 
tion,  etc.  Due  to  the  criticality  of  the  SEE  to  achievement  of  megaprogram¬ 
ming  objectives,  management  should  attempt  to  insulate  this  engineer  from 
the  host  of  non-technical  problems  that  are  sure  to  occur  (discussed 
above).  The  conventional  approach  is  to  treat  the  SEE  as  an  acquisition  and 
maintenance  problem;  thus,  the  engineering  aspects  of  the  SEE  tend  to  lag. 

4.2.3  SEE  Architecture  Lessons 

Lesson  6.  SEE  architecture  must  be  developed  incrementally. 

An  outside  consultant  cannot  present  an  organization  with  a  pre-integrated 
SEE  to  satisfy  product-line  objectives.  There  are  too  many  variations;  and 
too  much  needs  to  be  customized. 

At  the  start  of  the  Preparation  Phase  (10/92),  it  was  thought  that  Loral,  on 
behalf  of  STARS,  would  provide  an  off-the-shelf  SEE  that  would  be  fully  inte¬ 
grated  by  the  start  of  the  Performance  Phase  (10/93).  In  retrospect,  this  was 
naive. 

The  design  of  the  SEE  is  predicated  on  a  clear  statement  of  the  require¬ 
ments,  namely  the  automation  requirements  to  support  the  application 
product-line.  These  requirements,  in  turn,  are  dependent  on  the  organiza¬ 
tion’s  understanding  of  its  process.  In  the  case  of  the  Demonstration  Proj¬ 
ect,  some  aspects  of  the  basic  approach  were  still  being  worked  out  at  the 
beginning  of  the  Performance  Phase  -  let  alone  the  process. 

Thus,  by  the  end  of  the  Preparation  Phase,  Loral  and  the  Air  Force  were 
able  to  cite  one  of  the  major  lessons  learned  thus  far  on  the  Demonstration 
Project  -  one  that  transcends  the  SEE;  All  aspects  of  the  product-line  ap¬ 
proach  -  domain  models,  process,  application  architecture,  and  In  par¬ 
ticular  the  SEE  -  must  be  built-up  incrementally.  An  incremental,  iterative 
approach  is  necessary  since  the  organization  will  be  simultaneously  grap¬ 
pling  with  fundamental  approach  issues  -  delaying  the  availability  of  firm 
SEE  requirements. 

This  principle  is  recognized  by  [Brown92],  who  argues  for  “evolutionary  ap¬ 
proaches,  rather  then  revolutionary”. 

4.2.4  Platform  and  Tool  Selection  Lessons 

Lesson  7.  Heterogeneous  open-systems  platforms  can  provide  an  important  de¬ 
gree  of  flexibility. 

The  SCAI  SEE  includes  both  Sun  and  IBM  RISC  System/6000  platforms. 
The  Suns  were  part  of  the  existing  SEE  before  the  Demonstration  Project, 
but  the  project  decided  to  complete  the  SEE  with  IBM  platforms  and  to  net¬ 
work  the  Suns  and  IBMs  together.  Although  the  two  platforms  cannot  run 
each  others’  binaries,  it  is  commonplace  to  network  their  file  systems  to¬ 
gether  and  to  remotely  execute  applications  via  XWindow/Motif. 
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Although  having  the  two  platform  types  meant  that  maintenance  and  system 
management  was  more  complicated,  the  project  has  realized  some  im¬ 
portant  benefits.  New  tools  and  new  versions  of  tools  are  often  released  on 
one  platform  (usually  the  Sun)  and  then  ported  to  others  -  and  there  can  be 
quite  a  bit  of  time  between  ports.  The  project  has  thus  been  able  to  take 
early  advantage  of  new  releases  of  several  tools  during  this  period,  includ¬ 
ing  Rational  ROSE  and  Rational  SoDA.  It  has  also  been  able  to  take  ad¬ 
vantage  of  tools  that  run  only  on  one  platform,  such  as  the  STARS  PSE  (IBM 
platform),  and  ProDAT  (Sun). 

Thus,  the  additional  flexibility  provided  by  heterogeneous  platforms  can  at 
least  partially  offset  the  additional  maintenance  overhead. 

Lesson  8.  Pilots  are  an  important  vehicle  for  both  tool  selection  and  tool  usage. 

If  there  is  no  past  experience  with  a  tool,  the  best  method  of  in-depth 
evaluation  is  to  conduct  a  pilot.  The  purposes  of  the  pilot  are  twofold:  not 
only  to  determine  whether  to  accept  the  tool,  but  also  to  learn  how  best  to 
use  the  tool  and  how  to  best  integrate  it  into  the  SEE.  The  pilot  must  be 
based  on  realistic  usage  scenarios.  The  best  pilots  are  essentially  precur¬ 
sor  production  usages  on  non-critical  path  activities.  On  the  SCAI  project, 
we  piloted  Amadeus,  IBM  CMVC,  the  STARS  Process  Support  Environment 
(PSE)  toolset,  and  ProDAT. 

4.2.5  SEE  Integration  Lessons 

Lesson  9.  Upgrades  to  an  operating  system  (or  other  SEE  Infrastructural  com¬ 
ponents)  can  disrupt  Integration. 

In  an  integrated  SEE,  many  of  the  tools  will  depend  on  particular  versions  of 
other  tools  (or  parts  of  the  SEE),  so  that  upgrades  cannot  take  place  in  iso¬ 
lation.  Rather,  upgrades  have  to  be  coordinated  with  one  another.  Infras¬ 
tructural  tools  (such  as  operating  systems  or  data  bases)  have  many  de¬ 
pendencies,  so  special  care  must  be  taken  when  planning  an  upgrade  to 
them.  Some  upgrades  may  have  to  be  delayed  until  dependent  tools  can  be 
upgraded.  Code  may  even  have  to  be  written  to  temporarily  mitigate  the  ef¬ 
fect  of  upgrades.  We  recommend  building  a  tool  dependency  matrix,  to  bet¬ 
ter  understand  the  impact  of  proposed  upgrades. 
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Lesson  10.  High-payoff  integration  can  result  from  selecting  a  vendor  whose 
toolset  evolution  objectives  align  with  your  organization’s  goals. 

Two  examples  of  how  this  strategy  has  paid  off  for  the  Demonstration  Proj¬ 
ect  are  the  Rational  toolset  (Apex,  ROSE,  SoDA),  and  the  TRW  toolset 
(UNAS,  SALE,  and  the  RICC  tools’).  In  both  cases,  the  Demonstration  Proj¬ 
ect  organization  had  already  established  confidence  in  the  vendors,  and 
their  toolsets  were  already  on  a  path  that  matched  the  needs  of  the  SWSC 
product-line  objectives.  In  the  case  of  Rational,  the  project  is  committed  to 
Ada  (supported  by  Apex),  OO  modeling  (supported  by  ROSE)  and  docu¬ 
mentation  automation  (supported  by  SoDA).  In  the  case  of  TRW,  the  project 
is  committed  to  the  underlying  architectural  infrastructure  supported  by  the 
TRW  toolset.  The  Air  Force  choice  to  use  these  vendors’  solutions  for  the 
Demonstration  Project  has  worked  out  well,  since  both  have  since  pursued 
a  vigorous  product  improvement  cycle,  including  progressively  higher  de¬ 
grees  of  integration. 

Lesson  11.  Acquiring  a  single  vendor  toolset  is  usually  more  cost-effective  than 
integrating  separate  tools. 

The  foregoing  discussion  of  the  Rational  and  TRW  toolsets  illustrates  that 
off-the-shelf  integration  has  worked  quite  well  for  this  organization.  Although 
there  has  been  relatively  little  home-grown  integration  to  date,  experience 
suggests  that  the  following  advantages  and  drawbacks  should  be  weighed: 

•  Advantages  of  off-the-shelf  integration; 

Your  organization  will  require  less  maintenance  labor/expertise 
in-house. 

The  fewer  vendors  to  deal  with,  the  less  logistics  hassles;  the 
fewer  vendors,  the  less  glue.  Integration  complexity  increases  as 
the  number  of  tools/vendors  increases. 

The  vendor  takes  care  of  assuring  the  toolset  remains  integrated 
as  components  change;  whereas  if  the  integration  is  the  respon¬ 
sibility  of  the  local  organization,  there  are  considerable  head¬ 
aches  when  one  of  the  integrated  components  changes. 

-  With  more  concentrated  investment  in  a  single  vendor’s  product 
(as  opposed  to  scattered  investment  in  numerous  vendors),  you 
have  more  leverage  in  getting  the  single  vendor  to  accommodate 
your  specific  requirements. 

•  Drawbacks  of  off-the-shelf  integration: 

You  have  to  accept  the  vendor’s  integration,  and  you  still  have  to 
solve  the  integration  problems  with  other  tools. 

All  of  the  component  tools  in  the  integrated  toolset  have  to  be  up¬ 
dated  at  once. 


’■The  TRW  Reusable  Integration  Command  Center  (RICC)  tools  are  Display  Builder  and  RHMI  (both  available  commerdally),  Query 
Builder  and  Query  Processor  (GOTS),  and  Message  Builder  and  Generic  Message  Parser  (GOTS). 
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-  Sometimes  the  vendor’s  plans  do  not  match  well  with  your  own 
schedule.  For  example,  if  an  underlying  OS  or  DBMS  has  to 
change,  you  will  have  to  wait,  as  we  had  to,  for  the  vendor’s  total 
package  update,  instead  of  a  single  component’s  update.  If  you 
are  doing  your  own  integration,  you  can  swap  out  a  piece 
(reasons  for  swapping;  licensing  issues,  functionality,  etc.). 

It  may  be  hard  -  or  even  impossible  -  to  integrate  a  component  of 
a  monolithic  integrated  toolset  with  an  outside  tool.  A  monolithic 
toolset  may  have  missing  functionality  that  must  be  provided  by 
another  toolset  that  has  overlapping  functionality  with  the  first  - 
resulting  in  wasted  redundant  functionality  in  the  SEE.  (An  ex¬ 
ample  of  this  currently  is  Rational  Apex,  which  supports  version 
control  but  not  problem  tracking;  IBM  CMVC,  which  also  supports 
version  control  and  problem  tracking  but  does  not  provide  Apex’s 
semantic  understanding  of  Ada.) 

Lesson  12.  Maintaining  process  information  in  muitipie  forms  poses  a  significant 
maintenance  chaiienge. 

On  the  SCAI  project,  process  modeling  and  enactment  is  split  among  three 
tools.  ProDAT  supports  activity-based  modeling,  using  IDEF  notation  as  a 
basis;  PEAKS  supports  workflow  modeling  and  process-driven  planning, 
using  ETVX  notation  as  a  basis;  and  ProjectCatalyst  supports  workflow  exe¬ 
cution  and  coordination,  using  task  lists  and  agendas  as  a  basis.  Each  tool 
provides  its  own  independent  method  for  entering  and  storing  its  data,  and 
each  supports  a  different  set  of  process  modeling  notions.  Using  all  three 
tools  allows  the  project  to  take  advantage  of  the  unique  capabilities  of  each 
but  has  the  drawback  that  process  information  is  split  and  must  be  man¬ 
aged  carefully  to  keep  it  synchronized. 

The  SCAI  is  grappling  with  this  problem  now,  and  some  remedial  action  is 
in  progress.  First,  PEAKS  and  ProjectCatalyst  were  already  partially  inte¬ 
grated  and  share  a  common  relational  database  management  system  for 
their  data.  In  addition,  both  have  recently  been  upgraded  to  provide  better 
integration:  the  ProjectCatalyst  view  of  the  process  can  be  instantiated  from 
the  PEAKS  view.  Second,  the  potentially  voluminous  combination  of  IDEF 
diagrams  and  supporting  text  is  being  consolidated  into  a  single  database 
via  ProDAT.  Flopefully,  these  two  measures  will  greatly  reduce  the  mainte¬ 
nance  of  SCAI  process  information,  which  will  in  turn  increase  the  likelihood 
that  the  processes  will  actually  be  enacted  in  accordance  with  their  defini¬ 
tions  -  thereby  enabling  a  genuine  process  improvement  cycle. 
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Lesson  13.  Artifact  management  (notably  configuration  management)  is  a  cen¬ 
tral  integration  issue. 

Since  the  SEE’s  primary  role  is  to  provide  the  means  to  create,  maintain 
and  access  project  artifacts,  configuration  management  is  a  pre-eminent 
SEE  integration  issue.  At  the  time  of  this  report,  CM  support  on  the  SEE  is 
still  fragmented.  For  example,  IBM  CMVC  is  in  use  for  many  aspects  of  proj¬ 
ect  work  (e.g.,  most  problem  tracking),  and  Rational  Apex  CMVC  is  in  use  for 
Ada  code  development  (code  management  only,  no  problem  tracking),  but 
as  of  yet,  there  is  no  SEE  integration  between  the  two  -  although  some  pro¬ 
totyping  has  been  conducted  to  pave  the  way  for  future  integration. 

There  are  several  reasons  why  integration  lagged  in  this  key  area: 


«  The  CM  process  is  only  partially  defined.  There  is  a  high-level  IDEFq  de¬ 
scription,  but  the  project  is  still  grappling  with  nuts-and-bolts  definition 
of  artifacts,  how  they  will  be  constructed  and  managed,  how  they  will  be 
delivered  from  point  to  point  within  the  process,  and  how  the  directories 
should  be  set  up  on  the  SEE  to  support  this  work.  (A  complicating  factor 
is  that  developing  the  SCAI’s  new  megaprogramming  approach  has  in¬ 
volved  coming  to  grips  with  new  types  of  artifacts,  combined  in  new 
ways.) 

•  Several  candidate  CM  tools  must  be  considered,  three  of  which  are  al¬ 
ready  in  use  on  the  SCAI  (IBM  CMVC,  Rational  CMVC,  the  State  Data 
Repository  part  of  ProjectCatalyst),  and  many  more  of  which  are  tools 
currently  in  use  elsewhere  within  the  SWSC. 


•  CM-implications  of  defining  a  product-line  process  are  not  well  under¬ 
stood.  This  is  currently  an  active  research  topic. 

Lesson  14.  Use  of  Broadcast  Message  Server  (BMS)  messaging  services  re¬ 
quired  unanticipated  engineering  effort  to  provide  guaranteed  message 
delivery. 

The  integration  mechanism  within  IBM  AIX  SDE  WorkBench  -  the  Broadcast 
Message  Server  (BMS)  -  is  intended  for  dialog  communications,  so  rela¬ 
tively  sophisticated  programming  is  needed  on  both  sides.  The  way  we 
programmed  the  use  of  WorkBench  messaging  service  did  not  force  the 
startup  of  the  receiver  of  the  message.  As  a  consequence,  some  mes¬ 
sages  were  undelivered,  and  integrity  of  the  integration  between  the  tools 
was  lost.  We  now  understand  the  requirement  for  more  handshaking  and 
error  checking  within  the  message  event  loops. 

There  were  other  limitations  in  WorkBench  that  surfaced  during  the  SEE  in¬ 
tegration  effort.  Communications  between  tools  were  supported  only  within 
a  single  user  session.  The  IBM  WorkBench  product  is  an  implementation  of 
the  Hewlett-Packard  Broadcast  Message  Server  (BMS)  technology.  We  be¬ 
lieve  many  of  the  WorkBench  limitations  were  the  result  of  the  lagging  im¬ 
plementation  of  BMS  improvements. 
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The  emerging  standard  for  SEE  integration  messaging  is  found  in  Sun’s 
ToolTalk  [TooITalk94].  This  technology  is  part  of  the  emerging  industry 
standard  referred  to  as  the  Common  Desktop  Environment  (CDE).  All  the 
major  environment  platform  vendors  (Sun,  Hewlett-Packard,  IBM,  Digital, 
and  others)  have  agreed  to  provide  CDE  compliant  products  with  their  plat¬ 
forms.  We  believe  that  future  releases  of  AIX  will  provide  an  implementation 
of  BMS  (through  ToolTalk)  that  will  ease  most  of  the  limitations  that  we  en¬ 
countered. 

Lesson  15.  A  Process  Support  Environment  can  provide  an  effective  SEE  inte¬ 
gration  layer. 

[Brown92,  p.304]  discusses  the  fundamental  role  an  organization’s  process 
plays  in  establishing  requirements  for  a  SEE:  “Understanding  the  process 
must  precede  introduction  of  solutions.”  Prior  to  its  affiliation  with  the  Dem¬ 
onstration  Project,  Loral  conducted  extensive  R&D  in  the  area  of  process 
automation.  This  work  led  to  the  notion  of  a  “process  support  environment” 
(PSE). 

The  PSE  is  a  set  of  tools  which  supports  the  organization  in  defining  its 
process  and  then  using  the  process  as  the  basis  for  SEE-assisted  plan¬ 
ning  and  enactment.  Experience  in  developing  and  using  PSEs  -  including 
the  recent  experience  on  the  Demonstration  Project  -  has  led  to  the  view  that 
it  is  useful  to  think  of  the  PSE  as  an  abstract  integration  layer,  which  encap¬ 
sulates  the  organization’s  process  and  exports  the  SEE’s  functionality  to  the 
end-user  in  the  context  of  the  process.  This  layer  is  only  partially  realized  to 
date,  but  experience  has  already  shown  its  potential  for  implementing  proc¬ 
ess-driven  SEE  integration. 

Please  refer  to  a  more  extensive  discussion  of  the  PSE  in  Section  5.3,  “A 
Key  Integration  Layer:  The  Process  Support  Environment,"  on  page  27. 

Also  refer  to  related  lessons  12,  13,  and  16. 

4.2.6  SEE  Improvement  Lessons 

Lesson  16.  Process-driven  databases  are  a  good  basis  for  metrics. 

Process-driven  tools  can  provide  a  credible  source  of  measurements  to 
support  metrics,  since  the  measurements  are  driven  by  the  work  itself. 

There  are  two  notable  examples  where  this  principle  is  being  applied: 

•  Process-driven  planning  and  enactment 

ProjectCatalyst  tasks  are  tied  to  the  PEAKS-generated  plans  -  which  in 
turn  are  based  on  the  project’s  defined  process.  As  tasks  are  executed 
by  practitioners,  the  start  and  completion  dates  are  automatically  posted 
to  both  the  ProjectCatalyst  and  the  PEAKS  databases.  This  means  that 
task  leads  and  managers  are  provided  accurate  visibility  of  work  prog¬ 
ress  -  since  milestones  are  reached  only  in  accordance  with  the  defined 
process,  complete  with  prescribed  validations. 
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In  addition,  as  tasks  are  completed,  the  SEE  gathers  task  wall-clock 
time  (automatically)  and  expended  labor  statistics  (via  prompts  to  the 
user).  These  are  also  posted  to  the  ProjectCatalyst  and  PEAKS  data¬ 
bases  and  are  available  for  metrics  analysis. 

In  both  cases,  the  accuracy,  timeliness  and  completeness  of  the  data  is 
greatly  improved  by  the  fact  that  it  is  directly  tied  to  the  work  itself. 

•  Problem  and  change  tracking 

The  project  is  using  an  automated  tracking  system  to  track  not  only 
problems  but  also  suggested  improvements  and  work  orders  -  which 
are  entered  into  the  system  as  they  are  conceived.  The  system  tracks 
their  progress  as  problems  are  resolved  and  work  orders  implemented. 
We  can  quickly  compute  metrics  on  the  progress  and  easily  identify 
problem  areas. 

Here  again,  people  don’t  have  to  do  anything  special:  the  accuracy,  time¬ 
liness  and  completeness  of  the  measurement  data  is  derived  from  the 
fact  that  it  is  tied  directly  to  work  processes. 

Lesson  17.  Periodic  SEE  surveys  are  essential  to  the  organization’s  SEE  im¬ 
provement  cycle. 

Active  process  improvement  and  SEE  improvement  programs  are  central  to 
megaprogramming.  To  identify  needed  improvements,  the  SEE’s  end- 
users  must  be  regarded  as  customers.  We  have  conducted  two  SEE  sur¬ 
veys  to  date.  Feedback  was  sought  on  individual  tools,  SEE  integration 
among  the  tools,  and  system  management  support  responsiveness. 
[DemExp95]  contains  an  extensive  appendix  discussing  our  survey  tech¬ 
niques,  which  included  innovations  on  assessing  tools  as  well  as  on  de¬ 
termining  high-payoff  opportunities  for  improving  integration. 

The  following  are  some  of  the  survey  findings: 

•  Users  felt  the  SEE’s  functionality  was  adequate  for  their  work  and 
“headed  in  the  right  direction”. 

•  The  areas  of  tool  functionality  that  were  deemed  “strategic"  to  the  proj¬ 
ect’s  long  term  objectives  were: 

-  Ada  software  production  (currently  supported  by  Rational  Apex  and 
related  tools) 

-  Architectural  infrastructure  support  (currently  addressed  by  the  RICC 
tools) 

-  Object-oriented  and  information  modeling  (currently  addressed  by 
ROSE  and  Teamwork/IM) 

-  Metrics 

-  Process  definition  (currently  addressed  by  ProDAT  and  PEAKS). 

-  Documentation  and  automated  documentation  production  (currently 
addressed  by  FrameMaker  and  SoDA) 
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•  The  areas  of  SEE  integration  that  were  deemed  “strategic”  were: 

-  Configuration  management  -  with  most  other  SEE  areas 

-  Project  management  -  with  most  other  SEE  areas 

-  Metrics  -  with  most  other  SEE  areas 

-  Object-oriented  and  information  modeling  -  with  document  produc¬ 
tion  and  Ada  software  production 

-  Ada  software  production  -  with  architectural  infrastructure  tools  and 
software  certification 

-  Process  modeling  -  with  project  management  and  process  execu¬ 
tion 

Based  on  the  analysis  of  the  survey  results,  the  following  survey  improve¬ 
ments  will  be  taken  into  account  for  the  next  survey: 

•  A  larger  cross-section  of  the  end-user  population  will  be  surveyed  (40% 
vs  25%). 

•  Additional  judgments  will  be  requested  to  enhance  the  survey’s  utility  in 
deriving  metrics.  For  example,  people  were  asked  to  assess  the  im¬ 
portance  of  functionality  groupings  to  their  own  jobs;  they  should  also  be 
asked  to  estimated  the  importance  to  the  future  product-line  objectives. 

•  Users  will  be  asked  to  rate  the  value  of  the  survey  itself  -  as  well  as  to 
provide  suggestions  for  improvement. 

•  Outside  consulting  will  be  sought  to  review  survey  techniques  and  rec¬ 
ommend  improvements. 
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5.  Megaprogramming  AND  SEE  Integration 

5.1  Viewing  the  SEE  as  a  Megaprogramming  Product  Line 

Although  this  paper  is  primarily  an  experience  report,  the  authors  reflection 
has  led  us  to  an  interesting  extension  of  the  megaprogramming  approach  -  an  ex¬ 
tension  that  has  helped  us  to  better  understand  our  own  Demonstration  Project  ex¬ 
perience  and  one  that  may  be  of  use  to  others  in  plotting  the  course  for  their  SEE. 
The  realization  is  this:  the  SEE  itself  is  a  product-line  and  is  as  much  subject  to 
megaprogramming  principles  as  the  applications  it  supports. 

Consider  that  the  fundamental  intent  of  megaprogramming  is  to  enable  sys¬ 
tematic  reuse  across  a  product-line  of  applications  -  applications  that  are  under  the 
control  of  a  single  domain  manager,  and  whose  natures  are  similar  enough  to  merit 
a  common  engineering  approach.  As  shown  in  Figure  2,  it  is  natural  to  think  of  the 
organization’s  SEE  assets  as  several  logical  SEEs  -  even  if  they  share  nnany  of  the 
same  physical  assets  (workstations,  software  licenses,  network  connections,  etc.). 
In  effect,  each  application  has  its  own  supporting  SEE. 


Figure  2.  A  Product-Line  of  SEEs  in  Support  of  a  Product-Line  of  Appli¬ 
cations 


Although  we  want  the  maximum  commonality  across  this  group  of  SEEs  -  just 
as  we  do  with  a  product-line  of  applications  -  we  also  acknowledge  that  there  are 
unique  aspects  of  each.  For  example,  for  a  SEE  supporting  a  space  catalog  mainte¬ 
nance  application,  we  may  need  capabilities  which  are  not  needed  for  a  missile 
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warning  application  -  such  as  a  special  orbital  mechanics  analysis  support  package, 
or  a  Prolog  engine  to  support  rule-based  artificial  intelligence  research.  In  addition, 
although  the  megaprogramming  processes  for  each  application  follow  a  common 
process  architecture,  each  application  has  its  own  nuances  -  thus  each  SEE  must 
support  a  tailored  rendition  of  the  common  process. 

5.2  A»plying  Megaprogramming  Discipline  to  the  SEE 

Since  there  does  appear  to  be  a  product-line  of  SEEs,  the  natural  question  is: 
do  megaprogramming  principles  apply  to  developing,  maintaining,  and  evolving  the 
product-line?  Although  space  does  not  permit  a  detailed  analysis  here,  the  answer 
appears  to  be  yes,  as  illustrated  in  Table  4. 


Megaprogramming 

Principle 

Applicability  to  SEE  Product-Line 

•  Domain- 
Specific 

Reuse 

•  Domain  requirements  established  by  Application  Product-line’s  common  process 
framework  and  need  for  automated  support;  domain  engineering  is  appropriate  to 
establish  domain  models,  etc.,  for  the  SEE  Product-Line. 

•  Common  SEE  architecture  framework  (see  Table  5)  to  maximize  potential  for  reuse 

•  Common  artifact  management  strategy,  CM  strategy  (including  reuse  library) 

•  Common  toolset,  minimizing  iicense  costs,  minimizing  training  costs,  enabling 
maximum  use  of  common  integration 

•  Common  toolset  taiioring  and  integration  approach,  with  process  for  product-line 
adaptation  of  common  scripts  and  data 

•  Systematic 
Process 

•  View  application  product-line’s  processes  as  integral  to  the  SEE 

•  Use  formal  processes  for  SEE  procurement,  SEE  engineering,  SEE  assembly  and 
installation,  SEE  management  (problem  and  work  item  tracking)  -  and  SEE  im¬ 
provement  (including  survey  techniques) 

•  Automated 
Support 

•  Automated  tracking  tool  to  assist  with  SEE  administration 

•  Commercial  GUI  builder  for  locally-written  applications 

•  Commercial  integration  framework  services 

Table  4.  Applicability  of  Megaprogramming  Principles  to  SEE  Prod¬ 
uct-Line 


To  reiterate,  although  this  discussion  shows  that  a  product-line  mentality  is 
highly  appropriate  to  the  SEE  product-line,  it  is  only  on  reflection  that  our  group  has 
come  to  this  realization.  For  example,  we  did  not  start  the  Demonstration  Project  with 
a  concerted  effort  to  plan  out  our  SEE  using  domain  engineering.  As  it  turns  out, 
however,  we  now  can  see  that  we  have  been  using  product-line  thinking  as  we  de¬ 
cided  what  hardware  to  acquire  and  which  tools  were  strategic. 
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For  example,  Table  5  illustrates  how  our  current  SEE  exhibits  architectural 
characteristics  that  provide  a  good  foundation  for  domain-specific  reuse  for  the  SEE 
product-line. 


Architectural 

Characteristics 

Example  Sub-Categories 

SCAI  SEE  Domain 
Implementation  Examples 

•  Layered  architec¬ 
ture 

•  Common  underlying  operating 
system  environment 

•  Process  support  environment 

•  Major  functionality  encapsula¬ 
tions 

•  Unix,  TCP/IP,  NFS,  X 

.  STARS  PSE 

•  Rational’s  integration  family  of  Ada 
support  tools  (centered  around 
Apex) 

•  TRWs  integration  family  of  code 
generation  tools  supporting  the  ar¬ 
chitectural  infrastructure  (UNAS, 
RICC) 

•  Common  user  in¬ 
terface 

•  Common  window-handling 

•  Common  window  behavior  look 
and  feel 

•  Motif 

*  Open  Interface  (from  Neuron  Data), 
Display  Builder  (from  TRW) 

•  Common  program 
interface  mecha¬ 
nisms 

•  Low-level  API  services 

•  High-level  data  repository 
services 

•  Broadcast  Message  System  (part  of 
HP’s  SoftBench) 

•  TCP/IP  Sockets  (for  guaranteed 
message  delivery) 

.  COTS  DBMSs  (Oracle,  Sybase) 

•  Component  reuse 

•  COTS  tools 

•  Various 

Table  5.  Architecture  Characteristics  for  the  SEE  Product-Line 


Our  intent  here  is  not  to  say  we  have  done  a  remarkable  job  of  megapro¬ 
gramming  for  the  SEE  (after  all,  we  are  only  supporting  a  single  application  so  far), 
but  rather  to  say  we  believe  megaprogramming  applies  to  this  product  line. 

As  we  learn  more  about  how  to  do  megaprogramming,  we  look  forward  to  ap¬ 
plying  the  improved  techniques  and  practices  to  the  SEE  product-line  as  well. 
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5.3  A  Key  Integration  Layer:  The  Process  Support  Environment 

Figure  3  illustrates  how  each  of  the  three  megaprogramming  technology 
thrusts  is  brought  to  bear  to  engineer  the  product-line  SEE.  The  SEE  is  depicted  in 
the  center  of  the  diagram  as  two  layers  -  a  key  architectural  viewpoint  that  is  elabo- 


Figure  3.  The  Motivation  for  a  PSE  Encapsulation  Layer 


rated  below. 

A  key  consequence  of  this  line  of  reasoning  is  the  identification  of  an 
“encapsulation  layer”  that  can  be  instrumental  in  SEE  integration:  the  Process  Sup¬ 
port  Environment  (PSE).  As  depicted  in  Figure  4,  the  PSE  is  a  set  of  tools  and  asso¬ 
ciated  data  that  allows  an  organization  to  define,  carry  out,  and  improve  its  process.  It 
also  serves  as  an  integration  vehicle  for  orchestrating  the  rest  of  the  SEE. 
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Figure  4.  Conceptual  Model  for  a  Process  Support  Environment  En¬ 
capsulation  Layer 


The  result  is  a  unique  form  of  integration:  process  is  integrated  with  the  SEE, 
and  the  encoded  process  is  then  integrated  with  the  rest  of  the  SEE’s  tools  and  arti¬ 
facts.  Thus,  two  types  of  integration  are  occurring  simuitaneousiy. 

Figure  5  shows  how  the  PSE  layer  fits  in  context  with  an  abstract  architecture 
for  the  SEE  -  depicted  in  terms  of  several  other  possible  encapsulation  layers  that 
can  be  called  upon  to  carry  out  process  functions. 
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Figure  6  illustrates  the  PSE  currently  in  use  on  the  Demonstration  Project. 


Process  Pertormance 
Management 


Manual 

Automated  Support 


Figure  6.  The  Demonstration  Project  Process  Support  Environment 


The  PSE  layer  includes  the  STARS-sponsored  tools  PEAKS,  ProjectCatalyst, 
and  Amadeus.  PEAKS  is  used  to  model  the  process  using  a  graphical  ETA/X"  nota¬ 
tion  and  to  construct  a  process-driven  plan  for  the  project.  ProjectCatalyst  [ProjCat94] 
is  used  to  support  the  coordination  and  execution  of  the  process-driven  plan.  To  pro¬ 
vide  this  support,  ProjectCatalyst  imports  the  PEAKS  plan  and  presents  it  to  task 
leads  as  a  hierarchy  of  process  component  “pages”.  The  pages  list  the  work  tasks, 
inputs,  outputs,  verification  points,  and  lower-level  process  components  called  for  by 
the  process-driven  plan.  The  task  leads  use  these  pages  (which  look  much  like 
spreadsheets)  to  dispatch  tasks  to  engineers  and  to  monitor  status.  They  can  also 
refine  the  pages  to  add  additional  steps  not  part  of  the  formal  process.  As  each  task 
is  dispatched  to  the  designated  engineer,  ProjectCatalyst  supplies  a  “work  context”  to 
Process  Weaver,  providing  the  engineer  with  convenient  access  to  the  artifacts  (files, 
etc.)  and  the  SEE  tools  to  be  used  for  the  task.  As  tasks  are  completed  and  mile¬ 
stones  are  reached,  status  is  reported  dynamically  to  the  PEAKS  planning  database  - 

A 

ETVX  -  Entry,  Task,  Validation,  eXit  -  a  notation  for  depicting  process  sequenang. 
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providing  managers  with  up  to  the  minute  status  of  project  activities.  This  closed-loop 
SEE  mechanism  assures  the  project  that  its  work  is  taking  place  in  accordance  with 
the  process  and  that  status  information  is  based  on  completion  of  prescribed  valida¬ 
tions.  Further,  as  key  points  in  the  process  execution  are  reached,  measurement 
data  (such  as  labor  hours,  elapsed  clock  time,  automated  quality  measures,  etc.)  is 
captured  in  the  Amadeus  database,  assuring  that  resulting  metrics  are  similarly 
based  on  actual  work  processes  -  and  allowing  analysts  to  derive  credible  informa¬ 
tion  to  assist  with  process  improvement. 

The  basic  usage  paradigm  supported  by  the  STARS  PSE  toolset  seems 
promising  to  the  end-users.  Based  on  survey  feedback,  task  leads  seem  at  home 
with  ProjectCatalyst’s  concise  spreadsheet-like  way  of  viewing  their  delegated  work 
in  progress  and  appreciate  the  automatic  reporting  of  status  based  on  the  engineer¬ 
ing  work  starts  and  stops.  Engineers  have  indicated  that  they  appreciate  the  struc¬ 
tured  way  their  tasks  are  maintained  in  Process  Weaver  agendas,  as  well  as  the 
ability  to  quickly  navigate  to  their  work  product  files  from  their  work  contexts. 

As  discussed  in  the  Lessons  Learned  section,  however,  there  are  still  imple¬ 
mentation  difficulties  with  the  current  tools  that  would  have  to  be  overcome  before 
they  could  be  considered  for  production  use.  As  of  this  writing,  while  PEAKS  is  near¬ 
ing  commercialization,  it  appears  that  ProjectCatalyst  will  remain  a  prototype  imple¬ 
mentation.  Current  plans  are  to  implement  some  of  the  ProjectCatalyst  functionality 
in  PEAKS  and  to  continue  to  assess  other  avenues  for  supporting  the  automated  en¬ 
actment  aspects  of  the  PSE. 

Although  much  work  remains  to  fully  realize  a  Process  Support  Environment, 
experience  to  date  demonstrates  the  viability  of  the  ideas.  Interested  readers  should 
refer  to  the  paper  “Using  Process  to  Integrate  SEEs”  [Randall95],  also  published  in 
these  proceedings  -  which  further  elaborates  the  motivation  for  the  PSE  layer,  pro¬ 
vides  a  model  for  its  structure  and  interfaces,  and  discusses  a  number  of  lessons 
learned  specific  to  integrating  process  and  SEE. 

To  dramatize  the  relevance  and  timeliness  of  this  work,  the  April,  1994  STSC 
Report  on  SEE  Technology  [STSC94]  identified  seven  key  SEE  technology  areas  that 
have  received  insufficient  attention  to  date  and  in  which  the  industry  now  seems 
postured  to  make  significant  progress.  Of  these  seven  areas,  the  top  three  were 
process  modeling,  process  definition,  and  process  enactment  and  enforcement.  The 
PSE  encapsulation  layer  addresses  all  three  of  these  areas. 


6.  Conclusion 

We  have  used  the  three  megaprogramming  technology  thrusts  -  domain- 
specific  reuse,  systematic  process,  and  automated  support  -  as  the  basis  for  organ¬ 
izing  this  paper.  The  Air  Force/STARS  Demonstration  Project  is  in  the  midst  of  transi¬ 
tioning  megaprogramming  into  practice,  with  the  intent  to  parley  the  SCAI  application 
into  a  product-line  of  similarly  constructed  systems.  Although  the  team  has  been 
grappling  for  two  years  on  how  to  build  product-line  applications,  it  was  not  until  re¬ 
cently  that  it  occurred  to  us  to  apply  megaprogramming  to  the  Software  Engineering 
Environments  supporting  those  applications. 
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In  retrospect,  this  is  no  great  revelation.  In  a  product-line  organization,  each 
unique  application  will  be  built  using  a  unique  SEE.  In  both  cases,  however,  our  ob¬ 
jective  is  to  seek  out  -  and  exploit  -  commonality,  to  allow  the  systems  (applications 
and  supporting  SEEs)  to  be  constructed,  maintained  and  evolved  with  maximum  effi¬ 
ciency.  Thus,  to  effectively  support  an  application  product-line,  we  believe  a  me¬ 
gaprogramming  organization  must  engineer  a  SEE  product-line. 

We  have  used  this  thought  pattern  to  re-examine  the  lessons  learned  in  the 
SEE  section  of  the  most  recent  Demonstration  Project  Experience  Report 
[DemExp95].  This  paper  cites  26  SEE  lessons  that  we  believe  are  relevant  to  organi¬ 
zations  transitioning  to  megaprogramming  -  and  elaborates  17  of  them  in  some  de¬ 
tail.  It  should  be  noted  that  many  of  the  lessons  are  not  unique  to  transitioning  to  me¬ 
gaprogramming  -  they  apply  equally  well  to  organizations  undergoing  significant 
change  to  their  business  paradigms  and  wishing  to  transform  their  SEEs  as  well  as 
their  processes. 

We  closed  the  paper  with  a  reflective  section  on  megaprogramming  and  SEE 
integration,  which  we  hope  lays  some  of  the  theoretical  groundwork  for  a  more  formal 
development  of  how  to  apply  megaprogramming  principles  to  the  SEE  product-line. 

We  intend  to  pursue  the  following  during  the  remainder  of  the  Demonstration 
Project  and  beyond; 

•  Further  definition  of  theory  and  practice  for  a  SEE  product-line  -  notably 
domain  engineering  of  the  SEE  domain; 

•  Further  refinement  of  process  and  SEE  integration  -  as  introduced  in 
Section  5.3,  on  page  27,  and  as  discussed  in  detail  in  [Randall95],  also 
published  in  these  proceedings: 

•  Additional  integration  initiatives  for  the  SCAI  SEE  -  notably  in  the  areas 
of  process-driven  project  management,  configuration  management, 
metrics,  and  engineering  artifact  interrelationships; 

•  Evaluation  of  emerging  SEE  integration  technology  -  such  as  Sun’s 
ToolTalk  and  the  Common  Desktop  Environment  -  with  the  intent  of  set¬ 
ting  long-range  SEE  evolution  priorities;  and 

•  Participation  with  other  SWSC  groups  -  to  communicate  our  approach, 
understand  their  approaches,  and  develop  a  unified  SEE  strategy 
across  the  organization. 
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